home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0133.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  2.1 KB  |  41 lines
  1. > a) PEM is end-to-end; for it to have any value, both ends must be enabled
  2. > for PEM. Feasible for a small group, but not for ubiquitous e-mail (yet) -
  3. > just think of the key management problems for 20,000 naive users. How would
  4. > PEM fit into IMAP? It would render all IMAP's fancy MIME-searching features
  5. > useless, given that PEM specifically applies itself to the entire message.
  6. > All IMAP would see is a lot of encrypted stuff.
  7.  
  8. The issue of MIME-PEM incompatibility is a general one that affects many things
  9. besides IMAP. This is being addressed by the PEM working group; there is an
  10. Internet Draft available that describes one approach to resolving this. If this
  11. approach is used IMAP's MIME facilities change from being inappropriate for PEM
  12. processing to just the thing you need to do PEM processing.
  13.  
  14. There's more to PEM processing than getting at the PEM material in the message,
  15. however. In particular, the handling of certificates is a very nasty problem.
  16. An IMAP client using PEM must at a minimum be able to:
  17.  
  18. (1) Retrieve the current user's certificate (including the private key).
  19. (2) Obtain certificates for other users.
  20. (3) Validate certificates for other users (this is a complex topic in its
  21.     own right and one that can be broken up in several ways).
  22.  
  23. At present there are no established protocols for doing this. X.500 may provide
  24. part of the solution but really isn't positioned correctly -- you can use X.500
  25. to obtain certificates but the X.500 client has to do all the tracking, alias
  26. handling, and validation itself. A SUBSTANTIAL amount of code is involved in
  27. doing all this stuff... This is not desireable in a lightweight client. (Nor is
  28. having an entire OSI stack, although LDAP presents a viable solution in this
  29. area.)
  30.  
  31. What is needed is an extremely lightweight means of obtaining and checking
  32. certificates using a remote trusted server. This could be part of IMSP, I
  33. guess. If so, there has to be mutual authentication of client and server (a la
  34. Kerberos) and either the IMSP protocol must support encryption of various
  35. pieces of critical data or the entire data stream must be encrypted. I would
  36. prefer the former for performance reasons.
  37.  
  38.                 Ned
  39.  
  40.  
  41.